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Sieve Extension: Copying Without Side Effects 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2004). 

Abstract 
The Sieve scripting language allows users to control handling and 
disposal of their incoming e-mail. By default, an e-mail message 


that is processed by a Sieve script is saved in the owner’s "inbox". 
Actions such as "fileinto" and "redirect" cancel this default 


behavior. 

This document defines a new keyword parameter, ":copy", to be used 
with the Sieve "fileinto" and "redirect" actions. Adding ":copy" to 
an action suppresses cancellation of the default "inbox" save. It 


allows users to add commands to an existing script without changing 
the meaning of the rest of the script. 


1. Introduction 


The Sieve scripting language [SIEVE] allows users to control handling 
and disposal of their incoming e-mail. Two frequently used Sieve 
commands are "fileinto" (saving into a local message store, such as 
an IMAP server) and "redirect" (forwarding to another e-mail 
address). Both of these cancel the Sieve default behavior of saving 
into the user’s "inbox". 


But some users have the notion of forwarding an extra copy of a 
message for safekeeping to another e-mail address, or of saving a 
copy in a folder - in addition to the regular message delivery, which 
shouldn’t be affected by the copy. 
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If saving an extra copy is all the user wanted to do, 


fileinto "unfiltered"; 
keep; 


would do the job. The "keep" command does explicitly what the 
cancelled default behavior did. But the explicit "keep" is a poor 
substitute for the implicit "keep" when more processing follows: 


fileinto "unfiltered"; 
keep; 


if header "Subject" "MAKE MONEY FAST!!!" 
{ 


discard; 


} 


In this example, the "discard" is ineffective against the explicit 
"keep"; the discarded message still ends up in the user’s inbox. 


It is possible to generate Sieve code that perfectly expresses a 
user’s wishes, but such code quickly grows unwieldy because it needs 
to keep track of the state that the implicit "keep" would have had 
without the "fileinto" or "redirect" command. 


This extension tries to make life easier for user interface designers 
and script writers by allowing them to express the "copy" semantics 
directly. 


2. Conventions used 


Conventions for notations are as in [SIEVE] section 1.1, including 
use of [KEYWORDS] and "Syntax:" label for the definition of action 
and tagged arguments syntax. 


The capability string associated with extension defined in this 
document is "copy". 


3. "scopy" extension to the "fileinto" and "redirect" commands 
Syntax: 
"fileinto" [":copy"] <folder: string> 
"redirect" [":copy"] <address: string> 
If the optional ":copy" keyword is specified with "fileinto" or 


"redirect", the tagged command does not cancel the implicit "keep". 
Instead, it merely files or redirects a copy in addition to whatever 
else is happening to the message. 
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Example: 


require ["copy", "fileinto"]; 
fileinto :copy "incoming"; 


# ... more processing follows 
4. Security Considerations 


The "copy" extension makes it easier to eavesdrop on a user’s message 
stream without the user noticing. This was technically possible 
before if an attacker gained read/write access to a user’s Sieve 
scripts, but now an attacker no longer needs to parse a script in 
order to modify it. Write access to Sieve scripts must be protected 
as strongly as read/write access to e-mail, for example by using 
secure directory protocols such as correctly parameterized LDAP over 
TLS [LDAP]. 


Organizations that wish to monitor their users’ e-mail traffic must 
familiarize themselves with local data protection laws before 
creating stores of old e-mail traffic without control, or perhaps 
even knowledge, of the sender or intended recipients. 


Organizations that legally use "redirect :copy" to eavesdrop on 
correspondence (for example, by keeping a log to answer questions 
about insider trading at a later time) can avoid future problems by 
setting users’ privacy expectations correctly. 


5. IANA Considerations 


The following template specifies the IANA registration of the "copy" 
Sieve extension specified in this document. 


To: iana@iana.org 
Subject: Registration of new Sieve extension 


Capability name: copy 

Capability keyword: copy 

Capability arguments: N/A 

Standards Track: RFC 3894 

Person and email address to contact for further information: 


Jutta Degener 

Sendmail, Inc. 

6425 Christie Ave, 4th Floor 
Emeryville, CA 94608 


Email: jutta@sendmail.com 
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This information has been added to the list of Sieve extensions given 
on http://www.iana.org/assignments/sieve-extensions. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2004). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE 
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
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Intellectual Property 
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Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the IETF’s procedures with respect to rights in IETF Documents can 
be found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
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The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at ietf- 
ipr@ietf.org. 
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